1. Field of the Invention
The present invention relates to Device Management (DM) in a communication system. More particularly, the present invention relates to techniques for sessionless reporting by a DM Client.
2. Description of the Related Art
With the growth in ubiquitous communications technologies and systems, devices are increasing in functionality and complexity. However, with the increase in the functionality and complexity of the devices, a need for the management of the devices has developed. To address that need, the Open Mobile Alliance (OMA) established a Device Management (DM) Working Group to specify protocols and mechanisms that achieve management of devices. The OMA-DM Working Group has developed the OMA-DM specification, which defines a two-way protocol between a DM Server and a DM Client associated with a device that is used for remote management of the device. Hereafter, a device associated with a DM Client may be referred to as an OMA-DM device. Historically, the devices have been wireless devices, but of late, OMA-DM has begun addressing the remote management needs of all types of devices. Examples of OMA-DM include the setting of initial configuration information in devices, the subsequent installation and update of persistent information in devices, the retrieval of management information from devices, and the processing of events and alarms generated by devices.
An instance of an interaction between a DM sever and a DM Client is referred to as a DM session and may be initiated by either the DM Client or the DM Server. The DM Client is typically embedded at the device and the DM Server manages the device by invoking one or more commands on the DM Client. The DM Client processes the one or more commands and communicates a response back to the DM Server. Communication between the DM Server and the DM Client is implemented via the exchange of Synchronization Markup Language (SyncML) messages. SyncML is based on Extensible Markup Language (XML). The structure of the SyncML messages is defined by the SyncML Document Type Definition (DTD), which is defined by the OMA.
An example of a communication system employing OMA-DM is described below with reference to FIG. 1.
FIG. 1 illustrates an exemplary communication system employing OMA-DM according to the related art.
Referring to FIG. 1, the exemplary communication system employing OMA-DM may include a wired network 100, a wireless network 102, a wired device 110, a wireless device 112, a DM Server 120, and a DM Authority 130. Each of the wired device 110 and the wireless device 112 has associated therewith a DM Client (not shown). In addition, the DM Authority 130 may be an Operations Support System (OSS). In FIG. 1, solid lines represent physical connectivity and dotted lines represent logical connectivity.
The exemplary communication system employing OMA-DM illustrated in FIG. 1 is merely one of a number of possible implementations. For example, one of the wired network 100 and the wireless network 102 may be omitted. Alternatively, the wired network 100 and the wireless network 102 may be combined. Further, while the DM Server 120 and the DM Authority 130 are shown as connected to the wired network 100, one or both of the DM Server 120 and the DM Authority 130 may alternatively be connected to the wireless network 102.
To facilitate OMA-DM in the communication system illustrated in FIG. 1, a two-way protocol based on the OMA-DM specification is utilized between the DM Server 120 and the DM Client associated with wireless device 112, and between the DM Server 120 and the DM Client associated with the wired device 110. The DM Authority 130 may direct the DM operations of the DM Client associated with each of the wired device 110 and wireless device 112 via the DM Server 120. Only the interaction between the DM Server 120 and a DM Client associated with each of the wired device 110 and wireless device 112, is within the scope of the OMA-DM specification.
An example of a DM Server initiated DM session with a DM Client is described below with reference to FIG. 2.
FIG. 2 is a signal diagram for a DM Server initiated DM session with a DM Client in a communication system according to the related art.
Referring to FIG. 2, the DM Server initiated DM session between a DM Server 202 and a DM Client 204 includes two phases. The first phase is a setup phase 210 and the second phase is a management phase 220. The setup phase 210 includes an exchange of information for authentication and device information. The exchange of information in the setup phase 210 includes one instance of each of three packages, namely Package 0 (212), Package 1 (214), and Package 2 (216). Package 0 (212) is communicated from DM Server 202 to DM Client 204 and is referred to as a Notification Message. Package 1 (214) is communicated from DM Client 204 to DM Server 202. Package 1 (214) includes client initialization information and device information. The client initialization information includes client credentials. Package 2 (216) is sent from DM Server 202 to DM Client 204. Package 2 (216) includes server initialization information and an initial management operation. The server initialization information includes one or more server credentials.
The management phase 220 includes the exchange of one or more instances of two types of packages, namely Package 3 (222), and Package 4 (224). Package 3 (222) is communicated from DM Client 204 to DM Server 202. Package 3 (222) includes client response information to the management operation triggered by Package 2 (216). Package 4 (224) is communicated from DM Server 202 to DM Client 204. Package 4 (224) includes at least one of an additional management operation and one or more additional user interaction commands, if the DM session is continued beyond the Package 2 message 216. Additional cycles of a Package 3 message 222 and a Package 4 message 224 may be transmitted between the DM Server 202 and DM Client 204 until the DM session is terminated.
The OMA-DM protocol supports the notion of DM bootstrapping. DM bootstrapping is the process by which a DM Client transitions from an un-provisioned, empty state, to a state where it is able to initiate a DM session with an authorized DM Server. A DM Client that has already been bootstrapped can be further bootstrapped to enable the DM Client to initiate a DM session with a new DM Server. An example of the OMA-DM architecture is described below with reference to FIG. 3.
FIG. 3 illustrates an OMA-DM architecture according to the related art.
Referring to FIG. 3, the OMA-DM architecture includes a DM Server 340, a DM Client 310 and DM standard Management Objects (MOs) 320. The DM Client 310 and the DM standard MOs 320 are co-located in a device 300. The OMA-DM architecture may include additional structural elements. However, a description of additional structural elements of the OMA-DM architecture is omitted for conciseness.
The DM Server 340 and DM Client 310, which have been described above, communicate via interfaces DM-1 330 and DM-2 332. DM Client 310 communicates via interface DM-5 334 with the DM Standard MOs 320.
The DM protocol defines three standard Management Objects (MOs) 320 that all implementations of a DM Client 310 must support. These DM standard MOs 320 include DMAccount (DMAcc) MO 322, Device Information (DevInfo) MO 324 and Device Details (DevDetail) MO 326.
The DMAcc MO 322 is used to manage information pertaining to bootstrapped DM Server 340. There is a single instance of the DMAcc MO 322 for each bootstrapped DM Server 340. For each DM Server 340 that has been successfully bootstrapped for DM device 310, the corresponding DMAcc MO 322 maintains information on a DM Server IDentifier (ID), connectivity information, server address, server and client credentials, etc. The DevInfo MO 324 provides basic information about the device 300 associated with the DM Client 310. The basic information includes a device ID, a device manufacturer ID, a model ID, and language settings. The DevDetail MO 326 provides additional information about the device 300 associated with the DM Client 310. The additional information includes device type, Original Equipment Manufacturer (OEM), hardware version, firmware version, software version, an indication of whether the device 300 supports optional features (e.g., large-object handling capability), maximum depth of the management tree, maximum total length of any Uniform Resource ID (URI), and maximum total length of any URI segment.
The OMA-DM standard specifies that OMA-DM MOs be represented as a tree of named nodes. An example of an OMA DMAcc MO node tree according to the related art is provided in FIG. 4 as an example of an OMA-DM MO node tree.
FIG. 4 illustrates a DMAcc MO node tree according to the related art.
Referring to FIG. 4, a pictorial description of a tree of named nodes of a DMAcc MO of the related art is shown. The nodes depicted in FIG. 4 are outside the scope of the present disclosure and therefore a description of each node is omitted herein for conciseness. A description of each node depicted in FIG. 4 can be found in section 5.3.1 of version 1.2.1 of the OMA-DM Standardized Objects, the entire disclosure of which is hereby incorporated by reference.
Each node in a MO is the potential target for invoking a management operation from the DM Server. In order to perform some remote management action, the DM Server executes an operation on the corresponding node. Nodes are addressed using a URI. The URI of a node is the concatenation of the names of all the nodes from the root of the management tree, using ‘/’ as the delimiter. For example, the URI of the “Name” node of the DMAcc MO shown in FIG. 4 is “Node:<x>/Name”.
Recently the OMA has set up a Task Force dedicated to Machine-to-Machine (M2M) communication. The Task Force has observed that the current assumption about OMA-DM devices is that the OMA-DM devices have significant memory and processing power, and are connected to a fixed or wireless network. However, many of the OMA-DM devices currently being deployed in M2M solutions are microcontrollers with limited capabilities. For such microcontrollers, the OMA-DM of the related art is too heavy. To address this shortcoming, OMA-DM should be extended in terms of protocol, MOs, other network bearers, etc., to support restricted capability OMA-DM devices. Thus, there is a need for a new lightweight DM to support M2M capability-limited OMA-DM devices.
As described above, the OMA-DM Transaction Model of the related art is essentially a secure request/response protocol between a DM Server and a DM Client that runs within the context of a DM session. Once a DM session is established, the DM Server alternately sends commands to the DM Client and receives responses from the DM Client. The DM Client also informs the DM Sever about events that have occurred on the device, via unsolicited alerts. As described above, all the reporting from the DM Client to the DM Server is done within the context of a DM Session, in either Package 1 or Package 3. However, with OMA-DM version 1.3, the concept of Sessionless DM has been introduced. This allows a DM Server to send messages to previously bootstrapped DM Clients, outside the context of a DM session. The DM Client processes these messages but does not send back a response.
To extend OMA-DM to support M2M capability-limited OMA-DM devices, the Sessionless DM concept may be exploited. Accordingly, there is a need for a technique that exploits the Sessionless DM concept in order to support M2M capability-limited OMA-DM devices.